This is the Help System for the Omnipresent Widget Database System. In this introductory section and in the other help entries, you can highlight any words or phrases surrounded by two triangles, like this:
Word or phrase
... and press <L> (for Lookup) for more information about it. (You can highlight a word by double-clicking on it with the mouse or by pressing Shift-Ctrl-right arrow with your cursor at the beginning of a word. For more information, look up the Topic on
Editing Keys
The Omnipresent Widget Database System is a executive management tool used for tracking funds, products, production schedules, and contacts for the Omnipresent Widget company. Use it to:
enter
Data
execute
Queries
produce
Reports and Labels
Its central planning tool is the
Budget Table
, with which the company's costs can be forecast and compared with actual expenses for different financial quarters..
This entry explains the first query buttons in the Budget Table Data Entry screen and its use. Ordinarily, it would be created from the Comments snippet in the appropriate GET object.
This is a general help entry on data entry procedures for the Budget table. It should be called by the data entry window...
This entry could be called by windows titled "Pick ____" -- Browses that act as "drivers" for data entry window such as the Budget window in the Widget system.
xPrint Options -- info on your printer and setup.
See Also: Reports and Labels
This is a help entry on Queries.
See Also: Budget Table: Query 1, Budget Table Query 2
rThis is a general entry on Reports and Labels.
See also: Print Options
This is a general entry on data entry.
See Also: Budget Table, Product Table, Editing Keys
In a large system like the OmiPresent Widget application, you would probably want your users to specify their own data directory along with many other defaults. You would create a utility menu option and screen and save this information either as a .MEM file or as information in a special "system setup" table.
You could use indirect references to your files when opening them or, if screens and reports are permitted to open their
Allowing users to specify their own data paths
In a large system like the OmiPresent Widget application, you would probably want your users to specify their own data directory along with many other defaults. You would create a utility menu option and screen and save this information either as a .MEM file or as information in a special "system setup" table.
You could use indirect references to your files when opening them or, if screens and reports are designed to open and close their own files, as in the defaults and simple examples shown here, you'd issue a SET PATH statement to allow the data to be found.
Allowing users to specify their own data paths has several important advantages:
they can set up their disks any way that is comfortable for them;
they can maintain their data separately from their program files. This makes backup much easier and DOS and FoxPro will both be more efficient with fewer files in each directory!
they can maintain several sets of data if necessary -- for separate offices, separate fiscal years, or even "scratch" data to be used by new operators learning the system.
Your installation routines can create the necessary empty data files in each specified data directory if they are not found, as described in the INSTALL.PRG
In a large system like the OmiPresent Widget application, you would probably want your users to specify their own data directory along with many other defaults. You would create a utility menu option and screen and save this information either as a .MEM file or as information in a special "system setup" table.
You could use indirect references to your files when opening them or, if screens and reports are designed to open and close their own files, as in the defaults and simple examples shown here, you'd issue a SET PATH statement to allow the data to be found.
Allowing users to specify their own data paths has several important advantages:
they can set up their disks any way that is comfortable for them;
they can maintain their data separately from their program files. This makes backup much easier and DOS and FoxPro will both be more efficient with fewer files in each directory!
they can maintain several sets of data if necessary -- for separate offices, separate fiscal years, or even "scratch" data to be used by new operators learning the system.
Your installation routines can create the necessary empty data files in each specified data directory if they are not found, as described in the INSTALL.PRG as part of Chapter 20's low-level file function section.
In a large system like the OmiPresent Widget application, you would probably want your users to specify their own data directory along with many other defaults. You would create a utility menu option and screen and save this information either as a .MEM file or as information in a special "system setup" table.
You could use indirect references to your files when opening them or, if screens and reports are designed to open and close their own files, as in the defaults and simple examples shown here, you'd issue a SET PATH statement to allow the data to be found.
Allowing users to specify their own data paths has several important advantages:
they can set up their disks any way that is comfortable for them;
they can maintain their data separately from their program files. This makes backup much easier and DOS and FoxPro will both be more efficient with fewer files in each directory!
they can maintain several sets of data if necessary -- for separate offices, separate fiscal years, or even "scratch" data to be used by new operators learning the system.
Your installation routines can create the necessary empty data files in each specified data directory if they are not found, as described in the INSTALL.PRG as part of Chapter 20's low-level file function section. Alternatively, you could design error-trapping procedures that would create them the first time they are required.
DO widghelp WITH VARREAD(), PROMPT(),WONTOP(), ALIAS(), WTITLE()
DO _q2b0ynq7z IN LOCFILE("WIDGET2" ,"MPX;MPR|FXP;PRG" ,"Where is WIDGET2?")
\<Undo
CTRL+U
\<Redo
CTRL+R
Cu\<t
CTRL+X
\<Copy
CTRL+C
\<Paste
CTRL+V
Clear
Select \<All
CTRL+A
Goto \<Line...
\<Find...
CTRL+F
Find A\<gain
CTRL+G
R\<eplace And Find Again
CTRL+E
Replace All
Prefere\<nces...
\<Budget Entries
\<Products
Budget \<Categories
\<Departments
C\<ustomers
DO budget.spr
DO _q2b0ynqs7 IN LOCFILE("WIDGET2" ,"MPX;MPR|FXP;PRG" ,"Where is WIDGET2?")
DO budcat.spr
DO dept.spr
Open & \<Browse Table
\<Set Order
\<Goto Record
\<Locate Record
Close \<Table
A\<verage...
C\<ount...
Su\<m...
Calculat\<e...
\<Reports
DO getorder.spr
Budget Table Report #1
... etc...
DO _q2b0ynr8d IN LOCFILE("WIDGET2" ,"MPX;MPR|FXP;PRG" ,"Where is WIDGET2?")
\<Hide
\<Hide All
Sh\<ow All
Clea\<r
\<Move
CTRL+F7
\<Size
CTRL+F8
\<Zoom
CTRL+F10
Z\<oom
CTRL+F9
\<Cycle
CTRL+F1
\<Debug
\<Trace
\<Reindex
Pac\<k
\<Print...
Printer \<Setup...
\<Data Path
\<Error Log Maintenance
errlog.dbf2
DO _q2b0ynrps IN LOCFILE("WIDGET2" ,"MPX;MPR|FXP;PRG" ,"Where is WIDGET2?")
DO _q2b0ynrqv IN LOCFILE("WIDGET2" ,"MPX;MPR|FXP;PRG" ,"Where is WIDGET2?")
help Data Path
\<Update Error Log Entries
\<Copy Error Log to Floppy
\<Erase Old Error Log
DO _q2b0ynrxd IN LOCFILE("WIDGET2" ,"MPX;MPR|FXP;PRG" ,"Where is WIDGET2?")
WAIT WINDOW "Data Entry not yet available for this Table."
WAIT WINDOW "Feature not implemented."
_Q2B0YNPTHRESULTS
_Q2B0YNPVPTABLES
PTHNEWWIND
UTILITIES
REPORTS
ERRORLOGMA
YNPTHH
Courtesy of FoxApp...
product.app
WIDGSCRN
HPRODUCT
0YNPVP}
ask.spr
Do you wish to print?
@M NO,YES
TO PRINT NOCONSOLE
PREVIEW
big_itemf
ask.spr
Smallest entry to mark:
99999
REPORT FORM Model &where_out ENVIRONMENT
YESNO
0YNPVPPAUSE
HWHERE_OUT
BIG_ITEM
Reindexing cancelled.
THISFILE
HTHISNAME
GOT_CANCEL<
Ready to remove deleted FF
records?
@M NO ,YES
Pack cancelled.
Pack cancelled.
Packing F
file...
YESNO
GOT_CANCELTHISFILE
LTHISNAME
errlog
errlog
DO getlisting
Current Error Log Records
Type Your Notes on the Error that Occurred Here
We Appreciate Your Assistance!
System Listing [F2]
User Notes
Current
XSELECT
HERRLOG
CELLOGBROW
LUSERMEMO
USERNOTES
STARTUP
ERRDATE
MACHECKMEMO
ERRTIME
LISTING
ERRORLOG
DO_START
Type
{CTRL-W}
GOHERE
Errlog
ERRLOG
HLISTING
{CTRL-F1}
STARTUP
H_Q2B0YNQ7Z
_Q2B0YNQS7
_Q2B0YNR8D
_Q2B0YNRPS
_Q2B0YNRQV
_Q2B0YNRXD
CHECKMEMO
GETLISTING
DO_START
widglogo.spr
widget2.mpr
{ALT-S}{W}
SETUP
? ?WIDGLOGO
_ _ _WIDGET2
_ MPR
4CLEANUP
TALKz
RESOURCEz
RESOURCE
HELPz
ERROR
ERROR
SAFETYz
FULLPATHz
W_USER
Widghelp
DO Widgerror WITH LINENO(1), PROGRAM(), MESSAGE(), MESSAGE(1), ERROR(), WLAST(), WREAD(), WONTOP(), RDLEVEL()
RESOURCE
?OLDRESOURCHELP
_ _ _OLDHELP
_ GOT_CANCELOLDERROR
4OLDTALK
OLDVUE
OLDSAFE
OLDFULL
W_USER
CWIDGHELP
SUPPORTFF
ON ERROR &olderror
SET SAFETY &oldsafe
SET FULLPATH &oldfull
OLDRESOURCRESOURCE
COLDHELP
_HELP
_ OLDTALK
ELOLDVUE
4GOT_CANCELOLDERROR
OLDSAFE
OLDFULL
BAILOUT
CDBFNAME
WIN_NAME
_FILT_EXPR
SRCHTERM
_ACT3
_ _ SKIPVAR
_ _ _ _ Y
_ _ _ _
Browse
Browse
ATC(thisvar, readitem) > 0
Current table is F
THISVAR
RCTHISPROMPTTHISWIND
_THISFILE
THISTITLE
TOPIC
READITEM
LWINDOBJ
CURRFILE
MENUITEM
TALKz
????_errs
/43/1012/1149/1150/1151/1600/
/5/19/20/114/1707/
/1410/
/1/15/41/111/1115/1294/1643/1644/1705/
/124/1705/
/3/108/109/110/1502/1708/
/125/
/1910/1643/1644/1717/
The printer is not ready; RETRY or CANCEL?
RETRY
@M RETRY, CANCEL
Record/file in use; RETRY or CANCEL?
RETRY
@M RETRY, CANCEL
FILEOPEN
Index file error detected; re-creating indexes...
There is a problem with your program files. Please re-install.
cannot recover from this error;
press a key to clean up & exit.
A program exception has occurred; writing error log...
errlog
errlog.dbf2
errlog.fpt2
errlog
errlog
error number=FF
error message=
last error parameter=
program=
lineno=
last window=
top window
SCREEN
*is NOT*8
involved in current READ
read level=
rec. no.=
FFFR^
diskspace=
FFFF
K memory in use by user objects
K memory remaining
K total memory available to Fox
Printer Driver Installed
processor=
video card/monitor=
FILES=
Status listing
gramdiskf
Memory listing
survey.txt
ERRLINENO
ERRPROG
PTERRMSG
_ERRLINE
ERRNO
LASTWIND
READWIND
LTOPWIND
READNO
ERRPDSET
ERRTALK
PTBELLTONE
LOWMEM
_ERRSTR
MEMO_ERRS
INDX_ERRS
DISK_ERRS
FILE_ERRS
NETW_ERRS
LOCK_ERRS
PRTR_ERRS
DRVR_ERRS
ERR_ASK
_ _ _ ERR_RESET
GOT_CANCELOLDVUE
XSELECT
_ ERRLOG
_ _ERRDATE
_ ERRTIME
SNAPSHOT
LISTING
USERNOTES
ERRDATA
eGRAMDISK
TEMPFILE
CSURVEY
Debug
BELLz
SET BELL &oldbell
RLINENO
RPROG
PTOLDBELL
SET TALK &errtalk
ERRPDSET
SETUP
? ?
CLEANUP
WIDGHELP
WIDGERROR
BELLTONE
ERR_RESET
TALKz
COMPATIBLEz
Executive
Information
System
Que's USING FOXPRO 2 Model Application...
CURRAREA
QTALKSTAT
COMPSTAT
MPSTAT
TALKz
COMPATIBLEz
_q291dzhlo
_q291dzhlo
U S I N G F O X P R O 2
by Lisa C. Slater and Steven E. Arnott
This application was created from
the techniques and model database detailed in
@*HN \<More;\<Done
(800) 428-5331
ISBN 0-88022-703-6
Que Publishing
_q291dzhlo
CURRAREA
TALKSTAT
uCOMPSTAT
_Q291DZHLODONE
DZHLO_Q291DZI9S
About The Widget Application
widgbout.txt
uDONE
W_ABOUT
LOWIDGBOUT
1DZI9S_Q291DZI9S
TALKz
COMPATIBLEz
_q1g0nmphf
_q1g0nmphf
_q1g0nmphf
QUESTION
VALUE
VALID
NOVALID
CURRAREA
TALKSTAT
COMPSTAT
_Q1G0NMPHFDUMMY
_Q1G0NMSKE
m.valuef
m.valuef
m.valuef
m.valuef
m.valuef
CENTURYz
m.valuef
@3,getcol GET m.value SIZE &msize
@3,getcol GET m.value PICTURE (temp) SIZE &msize
MSIZE
GETCOL
VALID
VALUE
NOVALID
_Q1G0NMSKE
WIDGET2, a FoxPro 2 Application written as part of Que Publishing's _Using FoxPro 2_, adds the simple changes needed to use a Foundation READ to the data entry programs and basic procedures in WIDGET.APP.
It also incorporates many of the other techniques taught in the section of the book beginning with Chapter 14, including a skeletal customized help system, and some example error trapping and logging. (Hint -- if you want to see the error trapping in full action, you can use the Results menu's Browse option to open the WIDGHELP table; then try to Pack it from the Utilities menu. This error occurs because WIDGHELP is automatically opened read-only since it is already the active help file.)
WIDGET2 is designed using a "classic" program structure and flow as described in Chapter 14 and Chapter 16, as you'll find when you investigate WIDGET2.PJX.
All the added subprocedures needed to support this program flow (SETUP, CLEANUP, WIDGHELP, WIDGERROR) are added to the end of WIDGMAIN.
WIDGET2 is still not a real-life application. It doesn't use all the tables that are part of the Widget system (you'll find their structures in the final Appendix), just the ones which have data entry programs built in the book. The help system just contains a few entries, with a main entry designed to show an example of an "text-embedded menu" as described in Chapter 15, and others suggesting various ways to evaluate and call the current TOPIC.
Because some of the data entry programs built in the book are direct READs (as required in a FoxApp-generated application like PRODUCT.PJX) and some are indirect (as in the later examples we provide), the error-handling procedures cannot handle multi-user record-locking. However, they can handle the need to USE EXCLUSIVEly for a Pack or Reindex, so these Utilities options are created from short procedures rather than the native bar names used in WIDGET.APP.
We do not mean to suggest that you should imitate some of our inconsistencies -- the different kinds of READs were provided to give you different examples. Similarly, you would probably pick *one* of the styles of lookup popups provided in BUDGET.SCX to use for all your lookups, and you would probably settle on a different organization for your WIDGHELP file and procedure.
Here are some other differences you'll find between WIDGET2 and the original WIDGET.APP, and some additional notes on changes made to the projects from the instructions in the book:
Although it only includes one report on the menu, this example allows slightly more flexibility than the one in WIDGET. Notice that the screen ASK.SCX has been included in WIDGET2.PJX twice, to allow it to be generated both with an .SPR and a .PRG extension (this instruction is saved with the project record for the included file). The non-default .PRG extension allows it to be called as a UDF(). You'll find an example of this in the "Pack" selection on the WIDGET2 menu. Ordinarily, if you wanted to use a screen as a UDF you might only include it once and stipulate the .PRG extension. When you wanted to use it as a procedure you would DO the_scx_name with no extension, like any other PRG. However, this example allows you to see that a screen might be included several times in a project with different "generate options" each time.
The "About..." option and several others you'd expect to find in a full application have been added -- explore the menus. Some options that will never function under a READ have been removed. You'd have to remove still others, replacing them with procedure you'd write, if you planned to run this application under the Distribution Kit. (Once you've read this text, you will probably want to remove the
KEYBOARD "{ALT-S}{W}"
in WIDGMAIN that forces the "About Widget" option to be called at the beginning of the program.)
The unique-id code validation required for the Product table was added to the SCX in use by PRODUCT.APP (the one generated by FoxApp). Both Widget applications then DO PRODUCT.APP instead of PRODUCT.SPR, to show how you might include a dependent application in a larger project. The source code for this dependent application (including both copies of the PRODUCT.SCX) can be found in \MODEL\PRODUCT, since they are not needed by the two Widget applications as long as the PRODUCT.APP file is available.
The simple WAITPAGE() UDF needed by the report included as an example has been revised slightly to allow the pause between pages to be skipped in various situations. The report option for WIDGET2 incorporates the change by setting a variable to indicate that the pause is required (WIDGET's report menu option does not require a change).
See the Data Path option on the Utility menu in WIDGET2 for other suggested changes to use this application in the "real world". There are other small changes scattered throughout the applications you'll notice if you "dig" a little as you follow the text. ;-)
(For more information on purchasing the book, see the file QDISTRIB.TXT, in your main directory for the book's files. It contains a list of phone numbers and distributors. If you are using the shareware version of the source code disk, see the file QDISK.TXT in your main source disk directory for information on registering the disk and receiving additional sample programs.)
Please type your name here
Please fill out this questionnaire with any and all information that you feel might be help the Widget Application programming team track down and fix any system errors you encounter.
Your "detective work" will help us make the system run as smoothly as possible. Just type answers directly below
Were you using the mouse or the keyboard? Did you do anything differently than usual? (The sequence of the menu options that you chose would be especially helpful.)
If you have seen this problem before, does it happen every time you use this menu option? If not, do you notice any other pattern about when it happens? For example, does it happen when you hit many keys rapidly?
What else could be done to make this part of the system easier for you to use?
[information on contacting the programmers directly can go here. The SURVEY.TXT file which creates the questionnaire could be created with TEXTMERGE to put users in touch with many different people (system admin, programmers, etc), change phone numbers, etc. SURVEY.TXT is INCLUDED
in WIDGET2.APP but could be marked excluded for easy editing, also.]